MCGA Graphics Tutorial Lesson #2 by Jim Cook I have to apologize a little bit. The first lesson contained code for setting a pixel by directly altering video memory. This probably was a strange sight for those of you that do not understand video memory, how it's layed out and how to address it. I do hope you did get excited by workable code in the first lesson. Video memory in the MCGA Mode we are using is far simpler to understand than even Text mode display memory. Those of you that know all about text screen addressing, just scoffed. No, seriously, it is as simple. I will try to make this easy to understand, because it really is. There is an area in your computer's memory that holds the program that is currently running, as well as, COMMAND.COM and other system drivers. s Most of you realize that there is also a section of memory that holds all of the information regarding your video screen. In the MCGA #1 you will notice that we changed the value of a byte in memory to change the color of a pixel on the screen. This may seem magical to some, but it really isn't. The logic driving a video card is simply this: 1. Scan video memory and write the bytes you see there to the screen. 2. Repeat Step 1. Unlike COMMAND.COM and the program that's running, whose starting address in memory could be different depending on a multitude of factors, video memory is always at the same location. In MCGA mode, video memory begins at the 655,360th byte of computer memory. You may say that my computer only has 655,360 bytes of memory total (640K). Where does that memory reside? Don't quote me on this, but I believe that the video memory wholly resides on your graphics card. So, the graphics card is responsible for scanning this piece of memory many times per second, and displaying on the screen whatever color values are stored starting at byte 655,360. By the way, in hex (base 16) that number is $A0000, and we'll refer to it like that from now on. These color values that I referred to are numbers from 0 to 255. If we store the number 0 in every byte of screen memory and the computer thinks that 0 means black, which it usually does, the screen will instantly clear to black. That's how you do a screen clear in MCGA. The resolution of our screen is 320 pixels horizontal by 200 pixels vertical. That makes up a total of 64000 pixels per screen. A normal text screen only has 4000 bytes of screen memory, so you can see why we sometimes use assembly language. So, a very prehistoric screen clear procedure could look something like: Procedure ClearScreen (Color:Byte); var I : Word; begin For I := 0 to 64000 do Mem [$A000:I] := Color; end; You'll notice I had to break the number $A0000 into two numbers. This is called segment-offset addressing, and it is a throwback to the days when the engineers felt we would never need more than 640K of memory. Let me briefly explain. The memory address $A0000 and $A000:0000 are synonymous. To compute a virtual address from a seg:ofs address you perform the calcualtion: virtual := seg * 16 + ofs. This lets a programmer access over 1 meg of memory using 2 word size values. Don't ask... OK. Since we are pretty much all hackers at heart and I don't have a chalkboard, I'll illustrate video memory: 0 1 2 3 4 5 ---> up to pixel 319 +---+---+---+---+---+---+---+---+---+---+---+---+-- 0 + 0 | 1 | 2 | 3 | 4 | 5 | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+-- 1 +320|321|322|323|324| | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+-- 2 +640|641|642|643| | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+-- 3 + | | | | | | | | | | | | Assume, (I know, bad word), that this is a extreme closeup of the upper left corner of a MCGA screen. As a matter of fact the box 0 is the first pixel (the uppermost leftest most pixel) on the screen. Say, we want to make it white. In the default palette the color white is 255. All we have to do is say: Mem [$A000:0000] := 255; If we want to make the pixel below it white also, we type : Mem [$A000:0320] := 255; As you can see, segment:offset addressing actually comes in handy in addressing pixels on the screen. Since there are 320 pixels across and 200 Pixels up and down, the following formula returns the address of any pixel on the MCGA screen: (Y * 320) + X This is assuming the upperleft pixel is (0,0) and the lower right pixel is (319,199), and we will. Understanding screen addresses is essential to comprehending any of the code we will be developing, so if a point is not clear...POST a message. Don't be bashful about asking questions. Just a quick point...I did not go to school to learn this. This is something everyone can learn. Graphics is a subject that a lot gets written about, but not the guts of programming it. Many of you may opt for the easy way out (canned libraries) but to really understand your computer you have to know what's going on under the hood. Also, for laughs, try implementing a good animation program or GUI with the BGI.